PR #72388 allowed us to preserve the original TokenStream in more cases during proc-macro expansion, but had to be reverted due to a large number of regressions (See #72545 and #72622). These regressions fell into two categories

1. Missing handling for Groups with Delimiter::None, which are inserted during macro_rules! expansion (but are lost during stringification and re-parsing). A large number of these regressions were due to syn and proc-macro-hack, but several crates needed changes to their own proc-macro code.
2. Legitimate hygiene issues that were previously being masked by stringification. Some of these were relatively benign (e.g. a compiliation error caused by misusing quote_spanned!). However, two crates had intentionally written unhygenic macro_rules! macros, which were able to access identifiers that were not passed as arguments (see Crater run for PR #72388 - Recursively expand TokenKind::Interpolated in probably_equal_for_proc_macro #72622 (comment)).

All but one of the Crater regressions have now been fixed upstream (see https://hackmd.io/ItrXWRaSSquVwoJATPx3PQ?both). The remaining crate (which has a PR pending at sammhicks/face-generator#1) is not on crates.io, and is a Yew application that seems unlikely to have any reverse dependencies.

As @petrochenkov mentioned in #72545 (comment), not re-landing PR #72388 allows more crates to write unhygenic macro_rules! macros, which will eventually stop compiling. Since there is only one Crater regression remaining, since additional crates could write unhygenic macro_rules! macros in the time it takes that PR to be merged.